home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 608 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.4 KB
  1. From: mforget@elfhaven.ersys.edmonton.ab.ca (Michel Forget)
  2. Subject: Re: Digested Replies
  3. Date:     Fri, 17 Jun 1994 01:53:00 -0600
  4. Precedence: bulk
  5.  
  6. Hello Christian,
  7.  
  8. >As has been pointed out, the risk of data loss can be avoided. But even if
  9. >there were something to this, changing shortcuts that are used by virtually
  10. >every program on the ATARI and even on other platforms is simply out of the
  11. >question. Most programmers just won't do it. Also remember that many app-
  12. >lications on the ATARI are no longer supported, but still used, so dramatic
  13. >changes like this will probably end with 50% of the used applications using
  14. >the old way, the other 50% the new way. Don't do that. This also applies to
  15. >CONTRL-U. An existing well-established standard, even if not perfectly
  16. >designed, is better than different competing standards.
  17.  
  18. Yes!  This is exactly what I like to see; people are changing existing
  19. standards (or commonalities) much too often; no matter how odd a
  20. keypress may seem, it should still be used if it is used in a large
  21. segment of programs.
  22.  
  23. Another disturbing thing I have seen is people proposing how "Find"
  24. should work; there is already an accepted minimal standard; an application
  25. should have "Find", "Find Next".  "Find Previous" is not essential, nor
  26. is "Replace"/"Replace Next" (for some applications).  People are talking
  27. about putting "Find"/"Find Next" on the same key, though, or putting
  28. "Find Next"/"Replace Next" on the same key (with the exact same keypress
  29. I mean, not just a shifted variation).  This does not make sense to me,
  30. because the idea is confusing to users, non-obvious, and (the best
  31. argument) not supported by any program available.
  32.  
  33. >In practically all GUI apps I have seen Undo (while not in a modal dialog)
  34. >takes back the last change done to a document, even if one has switched to
  35. >a different window. This is also what Apple's Human Interface Guidelines
  36. >say. I think it's dangerous to make it have a different meaning depending
  37. >on wheter a dialog is topped or not. It doesn't affect the meaning of any
  38. >other menu commands except 'close window'.
  39.  
  40. UNDO is a dialog box may be nice (and I think that it is) but it is not
  41. really essential.  If all "Cancel" buttons have the same string (Cancel)
  42. then Alternate+C could just as easily be used.
  43.  
  44. >   Christian (R.O.M. logicware)
  45.  
  46.  
  47. -- 
  48. Michel Forget           \\   mforget@elfhaven.ersys.edmonton.ab.ca
  49. Electric Storm Software  \\  ess@tibalt.supernet.ab.ca
  50.